Was easiest thing to do and some stuff like physics + solutions + transform will need their own solutions but this makes generic stuff like hunger, guns, thirst easier. It's also setup so it shouldn't be too hard to do field deltas for transform / physics in a generic way for some stuff.

The other benefit is we can network a lot more stuff (e.g. VVable fields) and not worry about states bloating out.

Branched from electro's delta branch.

One thing I'm not sure on is how to handle backwards compatibility short of making every single dirty call a field-level one for a component.

I checked out net_graph and there is a noticeable drop for hunger + thirst but not sure how else to profile it (obviously CPU wise I expect it would be slower marginally, just due to having to check if it's a delta state or not). With that being said if it's like a single bool component or small it's probably faster to just do a full dirty and not use deltas due to the List overhead (though not sure how it gets serialized).

On master the 2 spikes go up to the same point but with field deltas one noticeably drops a lot.

Okay so I measured it:
477 payload size vs 97 for 4 hunger states. Gun states went down by ~80 per state. Most of the time it's not going to be worth it but if we know there's a big component state like guns or something else that updates frequently (e.g. UI component) or something we can do specific implementations for in hotpaths (i.e. transform and physics with specific deltas without the List<T> overhead) then it'll give big savings.